Onboarding users running `stash db install` (or any of the six other
DB-touching commands) without an exported `DATABASE_URL` would hit a
cryptic "Invalid stash.config.ts: databaseUrl received undefined"
error from Zod. The CLI already loads `.env.local` / `.env`* via
dotenv, but had no story for `--database-url` flags, local Supabase,
or a pasted-once one-off value.

Adds `src/config/database-url.ts` exporting `resolveDatabaseUrl()` —
called at the top of every DB-touching command before
`loadStashConfig`. It walks sources in order:

  1. `--database-url <url>` flag (explicit override)
  2. `process.env.DATABASE_URL` (shell, mise, direnv, dotenv files)
  3. `supabase status --output env` -> DB_URL, gated on `--supabase`
     or a `supabase/config.toml` in cwd
  4. Interactive `p.text` prompt (skipped under `CI=true` or
     non-TTY stdin)
  5. Hard fail with a source-naming error message

The resolved URL is mutated into `process.env.DATABASE_URL` (only
when env was unset/empty, or the source was an explicit flag) so the
existing scaffolded `process.env.DATABASE_URL!` reference in
`stash.config.ts` resolves transparently. The connection string is
never written to disk — `stash.config.ts` keeps its declarative env
reference. The source label is logged (`Using DATABASE_URL from
--database-url flag` / `from supabase status` / `from prompt`) but
the URL itself is never echoed.

Wired through `bin/stash.ts` argv (the parser already supports
`--key value`), HELP text updated. All seven DB-touching commands
(`db install`, `db push`, `db upgrade`, `db status`, `db validate`,
`db test-connection`, `schema build`) accept `--database-url` and
call the resolver before `loadStashConfig`.

After a prompt-sourced run, a `p.note` nudges the user to set
DATABASE_URL in the existing dotenv file (or `.env` if none exists)
so they don't get re-prompted next time.

Tests:
- 13 unit tests (`__tests__/database-url.test.ts`) covering each
  source, malformed flag, empty-string-env fallthrough, supabase
  fallthrough on missing binary / no-DB_URL output / no project,
  prompt-cancel, CI guard, non-TTY guard, hint-file detection.
- 2 E2E tests (`tests/e2e/database-url.e2e.test.ts`) driving the
  built binary through the pty harness: `--database-url` flag
  surfaces the source label and proceeds to (failing) connection,
  CI=true with no creds exits 1 with the CI message.

`init`/build-schema is intentionally NOT wired through the resolver:
it reads `process.env.DATABASE_URL` for provider hints pre-config and
should not trigger the prompt flow.

Note: stacks on top of #375 (the jiti default-export unwrap fix). The
resolver populates env, but `loadStashConfig` still needs the jiti
fix to read the resulting config correctly. Both PRs together
deliver the full onboarding experience.

…utation

The previous design had the resolver mutate `process.env.DATABASE_URL`
in-flight before `loadStashConfig`, with the scaffolded
`stash.config.ts` referencing `process.env.DATABASE_URL!`. Two issues:

  1. Reading the config file made it look like the URL only ever came
     from env, even when the user had passed `--database-url` or hit
     the supabase-status fallback. Misleading.
  2. Mutating `process.env` in-flight is a global side-effect.

New shape — the scaffolded config calls the resolver directly:

  import { defineConfig, resolveDatabaseUrl } from '@cipherstash/cli'
  export default defineConfig({
    databaseUrl: await resolveDatabaseUrl(),
  })

Reading the file tells you exactly how the URL is resolved. No env
side-effects.

Implementation:

- `withResolverContext({ databaseUrlFlag, supabase }, fn)` runs `fn`
  inside an `AsyncLocalStorage` scope. Any `resolveDatabaseUrl()`
  descendant in the async-flow reads the options via `als.getStore()`.
  Each `loadStashConfig` call gets its own scope, so concurrent loads
  don't step on each other (verified by a dedicated unit test).

- The ALS instance is stashed on `globalThis` under a
  `Symbol.for`-keyed slot. Necessary because tsup ships the library
  (`dist/index.js`) and the binary (`dist/bin/stash.js`) as separate
  bundles, each with its own copy of `database-url.ts`. A bare
  module-level ALS would produce two independent stores: the CLI sets
  context on the binary's instance, the user's config (loaded via
  jiti from inside the binary process) reads from the library's. The
  globalThis rendezvous gives both bundles a single shared instance.

- `resolveDatabaseUrl` returns `string` (was previously
  `{ url, source }`) so the scaffolded `databaseUrl: await
  resolveDatabaseUrl()` is direct. The source label is logged
  internally; not part of the return contract.

- All seven DB-touching commands stop calling `resolveDatabaseUrl`
  themselves. Instead they pass `{ databaseUrlFlag, supabase }` to
  `loadStashConfig`, which threads them into the ALS scope around the
  jiti-import.

- Prompt now opens with a `p.note` listing the alternative paths
  (--database-url flag, env var, .env file) so users aren't stuck in
  an interactive flow when a flag would do.

- `process.env.DATABASE_URL` is never mutated by this code.

Tests:

- Unit suite (16 tests, was 13) updated for the new return type and
  no-env-mutation invariant. Adds an explicit concurrency test:
  two `withResolverContext` scopes started in parallel each see their
  own flag value. This is the regression net for the ALS choice.

- E2E suite updated: the test fixture config imports
  `resolveDatabaseUrl` from an absolute path to `dist/index.js` (the
  tmp dir has no node_modules). Real users get a clean
  `import { resolveDatabaseUrl } from '@cipherstash/cli'`.

No legacy-config handling — this hasn't shipped yet, fresh installs
get the new template directly.

…v file

Two follow-ups from manual testing:

1. The prompt tip referred to ".env file" generically, even when the
   project had a `.env.local` (the post-resolution hint already
   matched the detected file, but the up-front tip didn't).

2. `db test-connection`'s connection-failure handler suggested
   "Check your databaseUrl in stash.config.ts or .env file". With
   the new design `stash.config.ts` doesn't carry the URL — it
   calls `resolveDatabaseUrl()` — so pointing users there is
   actively misleading.

Both messages now go through `detectDotenvFile(cwd)` (newly
exported) and the message factories
`messages.db.urlPromptTip(file)` and
`messages.db.urlConnectionFailedHint(file)`. The user sees the
exact dotenv file they have in their project, plus the other ways
they can specify the URL (--database-url flag, env var).

Adds a unit test covering the dynamic-tip behaviour for both the
detected-file and default-`.env` cases.

Lindsay flagged on PR #377 that the DB commands hard-code `npx
@cipherstash/cli ...` in their `p.intro` and warning messages —
some lines I touched in this PR, others pre-existing. #379 already
landed `runnerCommand(pm, ref)` + `detectPackageManager()` for
exactly this; sweeping the six DB commands to use it now.

A user who runs `bunx @cipherstash/cli db status` now sees
`bunx @cipherstash/cli db status` as the intro banner (was: always
`npx ...` regardless of how they invoked the CLI), and warnings
like "Run `bunx @cipherstash/cli db install` to install it" or
"run `pnpm dlx @cipherstash/cli db push` to create it" follow the
same rule.

Files touched (all already in this PR's diff for the resolver
plumbing):

- db/install.ts — intro
- db/upgrade.ts — intro + "run db install" warning
- db/push.ts — intro
- db/status.ts — intro + 2 warnings (db install, db push)
- db/validate.ts — intro
- db/test-connection.ts — intro

Out of scope: the help-banner usage examples in `bin/stash.ts` and
`auth/index.ts`. Those are documentation listing all supported
commands, not runtime "this is what I ran" labels — separate UX
question whether `--help` should pick a single runner or list all
four. The wizard reference in `db/install.ts:276` is a comment
inside a generated SQL file's header; same separate concern.